Typical multi-processor systems, such as x86-based systems, use hardware or firmware-coordinated protocol for re-initializing secondary CPUs to a known state before they are brought up inside system software (e.g., operating system or hypervisor). On x86-based systems, this means sending some special commands to an interrupt controller. On the next generation of ARM®64 systems, CPU state coordination will be done via special firmware calls (i.e., CPU on, CPU off).
However, in some current generation platforms, e.g., ARM®64 platforms, secondary CPU initialization is carried out with a “mailbox” approach, not via resident firmware calls. This approach, which may be implemented, for example, using Microsoft MP Startup for ARM platforms, relies on the boot firmware reserving some frames of physical memory (also referred to as “pages” herein) and “parking” the secondary CPUs in a code loop that checks a special location in this frame, also known as the “jump address slot.” The per-CPU reserved frames of memory are then reported to the system software via a firmware configuration mechanism, for example, via MADT (Multiple APIC Description Table) in situations where system power management is carried out in accordance with the ACPI (Advanced Configuration and Power Interface) standard.
To start running system software code on a secondary processor, the system software writes a physical address of a secondary boot code into the “jump address slot” for the desired CPU. The “parked” CPU will then notice the jump address slot changing to a non-zero value and jump to that physical address, thus beginning the sequence of secondary processor boot-up.